home *** CD-ROM | disk | FTP | other *** search
/ BUG 1 / BUGCD1996_0708.ISO / pc / util / minilin / minilin.exe / USR / LIB / PPP / README_L.{_9 < prev    next >
Text File  |  1994-06-30  |  29KB  |  655 lines
  1.  
  2. PPP for Linux                                             Version 1.0.1
  3. =============                                                  based on
  4.                                                               ppp-2.1.2
  5.                                                               June 1994
  6.  
  7. Michael Callahan    callahan@maths.ox.ac.uk
  8. Al Longyear         longyear@netcom.com
  9.  
  10.   Contents:
  11.     INTRODUCTION
  12.     CREDITS
  13.     FUTURE PLANS
  14.     INSTALLATION
  15.     GENERAL NETWORK CONFIGURATION
  16.     CONNECTING TO A PPP SERVER
  17.     IF IT WORKS
  18.     IF IT DOESN'T WORK
  19.     IF IT STILL DOESN'T WORK (OR, BUG REPORTS)
  20.     DYNAMIC ADDRESS ASSIGNMENT
  21.     SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS
  22.     ADDING MORE PPP CHANNELS
  23.     CHANGES FROM LINUX PPP 0.1.x
  24.     CONCLUSION
  25.  
  26.  
  27. INTRODUCTION
  28.  
  29. This is a PPP driver for Linux.  It has been used by many people and
  30. seems to be quite stable.  It is capable of being used either as a
  31. 'client'--for connecting a Linux machine to a local Internet provider,
  32. for example--or as a 'server'--allowing a Linux machine with a modem
  33. and an Ethernet connection to the Internet to provide dial-in PPP
  34. links.  (In fact, the PPP protocol does not make the distinction
  35. between client and server, but this is the way people often think
  36. about it.)
  37.  
  38. The PPP protocol consists of two parts.  One is a scheme for framing
  39. and encoding packets, the other is a series of protocols called LCP,
  40. IPCP, UPAP and CHAP, for negotiating link options and for
  41. authentication.  This package similarly consists of two parts: a
  42. kernel module which handles PPP's low-level framing protocol, and a
  43. user-level program called pppd which implements PPP's negotiation
  44. protocols.
  45.  
  46. The kernel module assembles/disassembles PPP frames, handles error
  47. detection, and forwards packets between the serial port and either the
  48. kernel network code or the user-level program pppd.  IP packets go
  49. directly to the kernel network code.  So once pppd has negotiated the
  50. link, it in practice lies completely dormant until you want to take
  51. the link down, when it negotiates a graceful disconnect.
  52.  
  53. CREDITS
  54.  
  55. I (MJC) wrote the original kernel driver from scratch.  Laurence
  56. Culhane and Fred van Kempen's slip.c was priceless as a model (a
  57. perusal of the files will reveal that I often mimicked what slip.c
  58. did).  Otherwise I just implemented what pppd needs, using RFC1331 as
  59. a guide.  For the most part, the Linux driver provides the same
  60. interface as the free 386BSD and SunOS drivers.  The exception is that
  61. Linux has no support for asynchronous I/O, so I hacked an ioctl into
  62. the PPP kernel module that provides a signal when packets appear and
  63. made pppd use this instead.
  64.  
  65. Al Longyear ported version 2.0.4 of pppd (from the free package
  66. ppp-2.0.4) to Linux.  He also provided several enhancements to both
  67. the kernel driver and the OS-independent part of pppd.  His
  68. contributions to Linux PPP have been immense, and so this release
  69. is being distributed over both our names.
  70.  
  71. The pppd program comes from the free distribution of PPP for Suns and
  72. 386BSD machines, maintained by Paul Mackerras.  This package lists
  73. "thanks to" Brad Parker, Greg Christy, Drew D. Perkins, Rick Adams and
  74. Chris Torek.
  75.  
  76.  
  77. FUTURE PLANS
  78.  
  79. The main missing feature is the ability to fire up a PPP connection
  80. automatically when a packet destined for the remote host is generated
  81. ("demand-dialing").  Work is progressing on this, but it involves some
  82. nontrivial design issues.
  83.  
  84.  
  85. INSTALLATION
  86.  
  87. This version of PPP has been tested on 1.0.x (x=0..9) and 1.1.x
  88. (x=0..14) kernels.  It will probably not work on kernels much earlier
  89. than this due to a change in the routing code.  If you have an earlier
  90. kernel, please upgrade.
  91.  
  92. joining the PPP channel of linux-activists:
  93.  
  94.       This isn't really part of installation, but if you DO use
  95.       Linux PPP you should do this.  Send a message with the line
  96.     X-Mn-Admin: join PPP
  97.       contained in the body to linux-activists-request@niksula.hut.fi
  98.       You can send to the list by mailing to
  99.       linux-activists@niksula.hut.fi and putting the line
  100.         X-Mn-Key: PPP
  101.       at the start of your message.
  102.  
  103.       The advantage of subscribing is that you'll be informed of
  104.       updates and patches, and you'll be able to draw on the
  105.       experience of many PPP users.  If you have a problem, I may not
  106.       be able to diagnose it, but someone else may have solved it
  107.       already.
  108.  
  109.       Note also that I do not read the linux Usenet newsgroups
  110.       regularly enough to catch any discussions of PPP; if you want to
  111.       reach the PPP audience you should join the linux-activists
  112.       channel.
  113.  
  114.       To leave the PPP mailing list :-(, send a message with the line
  115.         X-Mn-Admin: leave PPP
  116.       to linux-activists-request.
  117.  
  118. kernel driver installation:
  119.  
  120.       This depends on the kernel version you're using.
  121.  
  122.       Since 1.1.14, Linux kernels have had built-in support for PPP.
  123.       You'll be asked whether you want PPP when you run "make config".
  124.       It's as easy as that.
  125.  
  126.       In 1.1.13, PPP is there but the PPP line in config.in is
  127.       commented out.  If you have 1.1.13, you probably should just
  128.       upgrade anyway.
  129.  
  130.       Kernel versions prior to 1.1.13 (including all 1.0.x kernels)
  131.       have had (hidden) support for PPP in the kernel configuration
  132.       setup for quite some time.  Adding the PPP kernel driver is
  133.       easy:
  134.  
  135.     1) copy ppp.c from the linux subdirectory of the distribution
  136.            to drivers/net and ppp.h to include/linux
  137.     2) uncomment the CONFIG_PPP line in config.in
  138.         3) if you are using 1.1.3 or earlier (including 1.0.x):
  139.            uncomment the line in ppp.c that begins
  140.             /* #define NET02D
  141.            by removing the "/* " characters
  142.         4) in the top level of the kernel source
  143.                make config
  144.                make dep
  145.                make
  146.  
  147.       Reboot with the new kernel.  At startup, you should see
  148.       something like this:
  149.  
  150.   PPP: version 0.2.7 (4 channels) NEW_TTY_DRIVERS OPTIMIZE_FLAGS
  151.   TCP compression code copyright 1989 Regents of the University of California
  152.   PPP line discipline registered.
  153.  
  154.       Don't worry if the words in capitals on the first line are
  155.       slightly different.
  156.  
  157.       If you want more than 4 channels, see the section "ADDING MORE
  158.       PPP CHANNELS" below.
  159.  
  160.       Now, try looking at the contents of /proc/net/dev.  It should
  161.       look something like this:
  162.  
  163.   Inter-|   Receive                  |  Transmit
  164.    face |packets errs drop fifo frame|packets errs drop fifo colls carrier
  165.       lo:      0    0    0    0    0        0    0    0    0     0    0
  166.     ppp0:      0    0    0    0    0        0    0    0    0     0    0
  167.     ppp1:      0    0    0    0    0        0    0    0    0     0    0
  168.     ppp2:      0    0    0    0    0        0    0    0    0     0    0
  169.     ppp3:      0    0    0    0    0        0    0    0    0     0    0
  170.  
  171.       This indicates that the driver is successfully installed.
  172.  
  173.       (Of course, you should keep a kernel without PPP around, in case
  174.       something goes wrong.)
  175.  
  176. pppd installation:
  177.  
  178.       If you want to recompile pppd, go to the pppd subdirectory of
  179.       the installation.  Type
  180.          ln -s Makefile.linux Makefile
  181.          make
  182.       There will be some warnings when compiling lcp.c, upap.c and
  183.       chap.c but these are OK.
  184.  
  185.       If you want to recompile chat, consult README.linux in the chat
  186.       directory.
  187.  
  188.       To install, type 'make install' in the chat and pppd
  189.       directories.   This will put chat and pppd binaries in /usr/etc
  190.       and the pppd.8 manual page in /usr/man/man8.
  191.  
  192.       pppd needs to be run as root.  You can either make it setuid
  193.       root or just use it when you are root.  'make install' will try
  194.       to install it setuid root.  Making pppd setuid root is
  195.       convenient for a single-user machine, but has security
  196.       implications which you should investigate carefully before
  197.       making it available on a multiuser machine.
  198.  
  199. GENERAL NETWORK CONFIGURATION
  200.  
  201. Since many people don't use the Linux networking code at all until
  202. they get a PPP link, this section describes generally what's needed to
  203. get things running.  In principle none of this is special to PPP.  For
  204. more details, you should consult the relevant Linux HOWTOs.  If you
  205. already understand network setup, you can skip this section.
  206.  
  207. The first file that requires attention is the rc script that does
  208. network configuration at boot time, called /etc/rc.net or
  209. /etc/rc.d/rc.net.{1,2} or something similar, depending on your Linux
  210. distribution.  This file should 'ifconfig' the loopback interface lo,
  211. and should add an interface route for it.  These lines might look
  212. something like this:
  213.         $CONFIG lo 127.0.0.1
  214.     $ROUTE add loopback
  215. or
  216.         /sbin/ifconfig lo 127.0.0.1
  217.         /sbin/route add 127.0.0.1
  218.  
  219. However, it should *not* config an ethernet card or install any other
  220. routes (unless you actually have an ethernet card, in which case I'll
  221. assume you know what to do).  Many distributions will provide scripts
  222. that expect you to have an ethernet card.
  223.  
  224. You also need to decide whether you want to allow incoming
  225. telnet/ftp/finger, etc.  If so, you should have the rc startup script
  226. run the 'inetd' daemon.
  227.  
  228. Next, you should set up /etc/hosts to have two lines.  The first
  229. should just give the loopback or localhost address and the second
  230. should give your own host name and the IP address your PPP connection
  231. will use.  For example:
  232.      127.0.0.1  loopback localhost   # useful aliases
  233.      192.1.1.17  billpc.whitehouse.gov bill  # my hostname
  234. where my IP address is 192.1.1.17 and my hostname is
  235. billpc.whitehouse.gov.  (Not really, you understand.)  If your PPP
  236. server does dynamic IP address assignment, give a guess as to an
  237. address you might get (see also "Dynamic Address Assignment" below).
  238.  
  239. Finally, you need to configure the domain name system by putting
  240. appropriate lines in /etc/resolv.conf .  It should look something like
  241. this:
  242.      domain whitehouse.gov
  243.      nameserver 192.1.2.1
  244.      nameserver 192.1.2.10
  245. Assuming there are nameservers at 192.1.2.1 and 192.1.2.10, then when
  246. you get connected with PPP, you can reach hosts whose full names are
  247. 'hillarypc.whitehouse.gov' and 'chelseapc.whitehouse.gov' by the names
  248. 'hillarypc' and 'chelseapc'.  You can probably find out the right
  249. domain name to use and the IP numbers of nameservers from whoever's
  250. providing your PPP link.
  251.  
  252. CONNECTING TO A PPP SERVER
  253.  
  254. To use PPP, you invoke the pppd program with appropriate options.
  255. Everything you need to know is contained in the pppd(8) manual page.
  256. However, it's useful to see some examples:
  257.  
  258. Example 1: A simple dial-up connection.
  259.  
  260. Here's a command for connecting to a PPP server by modem.
  261.  
  262.   pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: whitewater' \
  263.       /dev/cua1 38400 -detach debug crtscts modem defaultroute 192.1.1.17:
  264.  
  265. Going through pppd's options in order:
  266.    connect 'chat etc...'  This gives a command to run to contact the
  267.     PPP server.  Here the supplied 'chat' program is used to dial a
  268.     remote computer.  The whole command is enclosed in single quotes
  269.     because pppd expects a one-word argument for the 'connect' option.
  270.     The options to 'chat' itself are:
  271.          -v            verbose mode; log what we do to syslog
  272.          ""            don't wait for any prompt, but instead...
  273.          ATDT5551212   dial the modem, then
  274.          CONNECT       wait for answer
  275.          ""            send a return (null text followed by usual return)
  276.          ogin: ppp word: whitewater    log in.
  277.    /dev/cua1  specify the callout serial port cua1
  278.    38400  specify baud rate
  279.    -detach   normally, pppd forks and puts itself in the background;
  280.         this option prevents this
  281.    debug  log status in syslog
  282.    crtscts  use hardware flow control between computer and modem
  283.         (at 38400 this is a must)
  284.    modem  indicate that this is a modem device; pppd will hang up the
  285.         phone before and after making the call
  286.    defaultroute  once the PPP link is established, make it the
  287.         default route; if you have a PPP link to the Internet this
  288.         is probably what you want
  289.    192.1.1.17:  this is a degenerate case of a general option
  290.         of the form  x.x.x.x:y.y.y.y  .  Here x.x.x.x is the local IP
  291.         address and y.y.y.y is the IP address of the remote end of the
  292.         PPP connection.  If this option is not specified, or if just
  293.         one side is specified, then x.x.x.x defaults to the IP address
  294.         associated with the local machine's hostname (in /etc/hosts),
  295.         and y.y.y.y is determined by the remote machine.  So if this
  296.         example had been taken from the fictional machine 'billpc',
  297.         this option would actually be redundant.
  298.  
  299. pppd will write error messages and debugging logs to the syslogd
  300. daemon using the facility name "local2".  (Verbose output from chat is
  301. the same.)  These messages may already be logged to the console or to
  302. a file like /usr/adm/messages; consult your /etc/syslog.conf file to
  303. see.  If you want to make all pppd and chat messages go to the
  304. console, add the line
  305.    local2.*                    /dev/console
  306. to syslog.conf; make sure to put one or more TAB characters between
  307. the two fields.
  308.  
  309. Example 2: Connecting to PPP server over hard-wired link.
  310.  
  311. This is a slightly more complicated example.  This is the script I run
  312. to make my own PPP link, which is over a hard-wired Gandalf link to an
  313. Ultrix machine running Morningstar PPP.
  314.  
  315.   pppd connect /etc/ppp/ppp-connect defaultroute noipdefault debug \
  316.       kdebug 2 /dev/cua0 9600
  317.  
  318. Here /etc/ppp/ppp-connect is the following script:
  319.   #! /bin/sh
  320.   /etc/ppp/sendbreak
  321.   chat -v -t60 "" \; "service :" blackice ogin: callahan word: PASSWORD \
  322.       black% "stty -echo; ppp" "Starting PPP now"  && sleep 5
  323.  
  324. This sends a break to wake up my terminal server, sends a semicolon
  325. (which lets my terminal server do autobaud detection), then says we
  326. want the service "blackice".  It logs in, waits for a shell prompt
  327. ("black%"), then starts PPP.  The -t60 argument sets the timeout to a
  328. minute, since things here are sometimes very slow.
  329.  
  330. The "&& sleep 5" causes the script to pause for 5 seconds, unless chat
  331. fails in which case it exits immediately.  This is just to give the
  332. PPP server time to start (it's very slow).  Also, the "stty -echo"
  333. turned out to be very important for me; without it, my pppd would
  334. sometimes start to send negotiation packets before the remote PPP
  335. server had time to turn off echoing.  The negotiation packets would
  336. then get sent back to my local machine, be rejected (PPP is able to
  337. detect loopback) and pppd would fail before the remote PPP server even
  338. got going.  The "stty -echo" command prevents this confusion.  This
  339. kind of problem should only ever affect a *very* few people who
  340. connect to a PPP server that runs as a command on a slow Unix machine,
  341. but I wanted to mention it because it took me several frustrating
  342. hours to figure out.
  343.  
  344. The pppd options are mostly familiar.  Two that are new are
  345. "noipdefault" and "kdebug 2".  "noipdefault" tells pppd to ask the
  346. remote end for the IP address to use; this is necessary if the PPP
  347. server implements dynamic IP address assignment as mine does (i.e., I
  348. don't know what address I'll get ahead of time).  "kdebug 2" sets the
  349. kernel debugging level to 2, enabling slightly chattier messages from
  350. the ppp kernel code.
  351.  
  352.  
  353.  
  354. Anyway, assuming your connection is working, you should see chat dial
  355. the modem, then perhaps some messages from pppd (depending on your
  356. syslog.conf setup), then some kernel messages like this:
  357.  
  358.     ppp: channel ppp0 mtu changed to 1500
  359.     ppp: channel ppp0 open
  360.     ppp: channel ppp0 going up for IP packets!
  361.  
  362. (These messages will only appear if you gave the option "kdebug 2" and
  363. have kern.info messages directed to the screen.)  Simultaneously, pppd
  364. is also writing interesting things to /usr/adm/messages (or other log
  365. file, depending on syslog.conf).
  366.  
  367. IF IT WORKS
  368.  
  369. If you think you've got a connection, there are a number of things you
  370. can do to test it.
  371.  
  372. First, type
  373.     /sbin/ifconfig
  374. (ifconfig may live elsewhere, depending on your distribution.)  This
  375. should show you all the network interfaces that are 'UP'.  ppp0 should
  376. be one of them, and you should recognize the first IP address as your
  377. own and the "POINT-TO-POINT ADDR" as the address of your server.
  378. Here's what it looks like on my machine:
  379.  
  380. lo        Link encap Local Loopback  
  381.           inet addr 127.0.0.1  Bcast 127.255.255.255  Mask 255.0.0.0
  382.           UP LOOPBACK RUNNING  MTU 2000  Metric 1
  383.           RX packets 0 errors 0 dropped 0 overrun 0
  384.           TX packets 0 errors 0 dropped 0 overrun 0
  385.  
  386. ppp0      Link encap Serial Line IP  
  387.           inet addr 192.76.32.2  P-t-P 129.67.1.165  Mask 255.255.255.0
  388.           UP POINTOPOINT RUNNING  MTU 1500  Metric 1
  389.           RX packets 33 errors 0 dropped 0 overrun 0
  390.           TX packets 42 errors 0 dropped 0 overrun 0
  391.  
  392. Now, type
  393.     ping z.z.z.z
  394. where z.z.z.z is the address of your server.  This should work.
  395. Here's what it looks like for me:
  396.   waddington:~$ ping 129.67.1.165
  397.   PING 129.67.1.165 (129.67.1.165): 56 data bytes
  398.   64 bytes from 129.67.1.165: icmp_seq=0 ttl=255 time=268 ms
  399.   64 bytes from 129.67.1.165: icmp_seq=1 ttl=255 time=247 ms
  400.   64 bytes from 129.67.1.165: icmp_seq=2 ttl=255 time=266 ms
  401.   ^C
  402.   --- 129.67.1.165 ping statistics ---
  403.   3 packets transmitted, 3 packets received, 0% packet loss
  404.   round-trip min/avg/max = 247/260/268 ms
  405.   waddington:~$
  406.  
  407. Try typing:
  408.     netstat -nr
  409. This should show three routes, something like this:
  410. Kernel routing table
  411. Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
  412. 129.67.1.165    0.0.0.0         255.255.255.255 UH    0      0        6 ppp0
  413. 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
  414. 0.0.0.0         129.67.1.165    0.0.0.0         UG    0      0     6298 ppp0
  415.  
  416. If your output looks similar but doesn't have the destination 0.0.0.0
  417. line (which refers to the default route used for connections), you may
  418. have run pppd without the 'defaultroute' option.
  419.  
  420. At this point you can try telnetting/ftping/fingering whereever you
  421. want, bearing in mind that you'll have to use numeric IP addresses
  422. unless you've set up your /etc/resolv.conf correctly.
  423.  
  424. IF IT DOESN'T WORK
  425.  
  426. If you don't seem to get a connection, the thing to do is to collect
  427. 'debug' output from pppd.  To do this, make sure you run pppd with the
  428. 'debug' option, and put the following two lines in your
  429. /etc/syslog.conf file:
  430.     local2.*                    /dev/console
  431.     local2.*                    /usr/adm/ppplog
  432. This will cause pppd's messages to be written to the current virtual
  433. console and to the file /usr/adm/ppplog.  Note that the left-hand
  434. field and the right-hand field must be separated by at least one TAB
  435. character.  After modifying /etc/syslog.conf, you must execute the
  436. command 'kill -HUP <pid>' where <pid> is the process ID of the
  437. currently running syslogd process to cause it to re-read the
  438. configuration file.
  439.  
  440. Some messages to look for: 
  441.   - "pppd[NNN]: Connected..." means that the "connect" script has
  442.     completed successfully.  
  443.   - "pppd[NNN]: sent [LCP ConfReq"... means that pppd has attempted to
  444.     begin negotiation with the remote end.  
  445.   - "pppd[NNN]: recv [LCP ConfReq"... means that pppd has received a
  446.     negotiation frame from the remote end.
  447.   - "pppd[NNN]: ipcp up" means that pppd has reached the point where
  448.     it believes the link is ready for IP traffic to travel across it.
  449.  
  450. If you never see a "recv" message then there may be serious problems
  451. with your link.  (For example, the link may not be passing all 8
  452. bits.)  If that's the case, it would be useful to collect a debug log
  453. which contains all the bytes being passed between your computer and
  454. the remote PPP server.  To do this, alter your syslog.conf lines to
  455. look like this
  456.     local2.*,kern.*                /dev/console
  457.     local2.*,kern.*                /usr/adm/ppplog
  458. and HUP the syslog daemon as before.  Then, run pppd with the option
  459. "kdebug 5".  Whatever characters arrive over the PPP terminal line
  460. will appear in the debugging output.
  461.  
  462. Occasionally you may see a message like
  463.    ppp_toss: tossing frame, reason = 4
  464. The PPP code is throwing away a packet ("frame") from the remote
  465. server because of a serial overrun.  This means your CPU isn't able to
  466. read characters from the serial port as quickly as they arrive; the
  467. best solution is to get a 16550A serial chip, which gives the CPU some
  468. grace period.  Reasons other than 4 indicate other kinds of serial
  469. errors, which should not occur.
  470.  
  471. During the initial connection sequence, you may see one or more
  472. messages which indicate "bad fcs".  This refers to a checksum error in
  473. a received PPP frame, and usually occurs at the start of a session
  474. when the peer system is sending some "text" messages, such as "hello
  475. this is the XYZ company".  Messages of "bad fcs" once the link is
  476. established and the routes have been added are not normal and indicate
  477. transmssion errors or noise on the telephone line.
  478.  
  479. IF IT STILL DOESN'T WORK (OR, BUG REPORTS)
  480.  
  481. If you're still having difficulty, send the linux-activists PPP
  482. channel a bug report.  It is extremely important to include as much
  483. information as possible; for example:
  484.  - the version number of the kernel you are using
  485.  - the version number of Linux PPP you are using
  486.  - the exact command you use to start the PPP session
  487.  - log output from a session run with the 'debug' option, captured
  488.    using local2.*,kern.* in your syslog.conf file
  489.  - the type of PPP peer that you are connecting to (eg, Xyzzy Corp
  490.    terminal server, Morningstar PPP software, etc)
  491.  - the kind of connection you use (modem, hardwired, etc...)
  492.  
  493. DYNAMIC ADDRESS ASSIGNMENT
  494.  
  495. You can use Linux PPP with a PPP server which assigns a different IP
  496. address every time you connect.  You need to use the 'noipdefault'
  497. option to tell pppd to request the IP address from the remote host.
  498.  
  499. Sometimes you may get an error message like "Cannot assign requested
  500. address" when you use a Linux client (for example, "talk").  This
  501. happens when the IP address given in /etc/hosts for our hostname
  502. differs from the IP address used by the PPP interface.  The solution
  503. is to use ifconfig ppp0 to get the interface address and then edit
  504. /etc/hosts appropriately.
  505.  
  506. SETTING UP A MACHINE FOR INCOMING PPP CONNECTIONS
  507.  
  508. Suppose you want to permit another machine to call yours up and start
  509. a PPP session.  This is possible using Linux PPP.
  510.  
  511. Before doing anything else, you should make sure that your Linux
  512. machine is set up to answer incoming calls and provide login prompts
  513. over the serial line.  You should verify that you can dial up, log in
  514. as a normal user, get a shell prompt, and issue some commands.  This
  515. document does not discuss how to set up a Linux machine to answer
  516. incoming calls; for that, refer to the documentation that came with
  517. your distribution or the Serial HOWTO.
  518.  
  519. Now, to provide PPP service, one way is to create an account named,
  520. say, 'ppp', with the login shell being a short script that starts
  521. pppd.  For example, the /etc/passwd entry might look like this:
  522.  
  523.   ppp:(encrypted password):102:50:PPP client login:/tmp:/etc/ppp/ppplogin
  524.  
  525. Here the file /etc/ppp/ppplogin would be an executable script
  526. containing something like:
  527.  
  528.   #!/bin/sh
  529.   exec /usr/etc/pppd passive :192.1.2.23
  530.  
  531. Here we will insist that the remote machine use IP address 192.1.2.23,
  532. while the local PPP interface will use the IP address associated with
  533. this machine's hostname in /etc/hosts.  The 'passive' option (which is
  534. not required) just means that pppd will try to open negotiations when
  535. it starts, but if it receives no reply it will just wait silently.
  536. This is appropriate if the remote end might take some time before it's
  537. ready to negotiate.  (Note that the meaning of the 'passive' option
  538. changed between ppp-1.3 and ppp-2.0.)
  539.  
  540. This setup is sufficient if you just want to connect two machines so
  541. that they can talk to one another.  If you want to use Linux PPP to
  542. connect a single machine to an entire network, or to connect two
  543. networks together, then you need to arrange for packets to be routed
  544. from the networks to the PPP link.  Setting up a link between networks
  545. is beyond the scope of this document; you should examine the routing
  546. options in the manual page for pppd carefully and find out about
  547. routed, etc.
  548.  
  549. Let's consider just the first case.  Suppose you have a Linux machine
  550. attached to an Ethernet, and you want to allow its PPP peer to be able
  551. to communicate with hosts on that Ethernet.  To do this, you should
  552. have the remote machine use an IP address that would normally appear
  553. to be on the local Ethernet segment and you should give the 'proxyarp'
  554. option to pppd on the server.  Suppose, for example, we have this
  555. setup:
  556.  
  557.  192.1.2.23                        192.1.2.17
  558. +-----------+      PPP link       +----------+
  559. | chelseapc | ------------------- |  billpc  |
  560. +-----------+                  +----------+
  561.                                         |           Ethernet 
  562.                             ----------------------------------- 192.1.2.x 
  563.  
  564. Here the PPP and Ethernet interfaces of billpc will have IP address
  565. 192.1.2.17.  (It's OK for one or more PPP interfaces on a machine to
  566. share an IP address with an Ethernet interface.)  There is an
  567. appropriate entry in /etc/passwd on billpc to allow chelseapc to call
  568. in, with the /etc/ppp/ppplogin script containing
  569.   #!/bin/sh
  570.   exec /usr/etc/pppd passive proxyarp :192.1.2.23
  571. When the link comes up, pppd will enter a "proxy arp" entry for
  572. chelseapc into the arp table on billpc.  What this means effectively
  573. is that billpc will pretend to the other machines on the 192.1.2.x
  574. Ethernet that its Ethernet interface is ALSO the interface for
  575. chelseapc (192.1.2.23) as well as billpc (192.1.2.17).  In practice
  576. this means that chelseapc can communicate just as if it was directly
  577. connected to the Ethernet.
  578.  
  579. ADDING MORE PPP CHANNELS
  580.  
  581. By default, Linux PPP comes with 4 kernel channels, which means that
  582. at most 4 simultaneous PPP sessions are possible.  If you desire more
  583. such sessions (for example if you are serving many dialup lines), you
  584. can easily reconfigure the kernel to add new channels.  There are two
  585. steps.
  586.  
  587. First you need to edit the kernel file drivers/net/Space.c .  As
  588. distributed, it contains a section that looks like this:
  589.   
  590. #if defined(CONFIG_PPP)
  591. extern int ppp_init(struct device *);
  592. static struct device ppp3_dev = {
  593.     "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, NEXT_DEV,  ppp_init, };
  594. static struct device ppp2_dev = {
  595.     "ppp2", 0x0, 0x0, 0x0, 0x0, 2, 0, 0, 0, 0, &ppp3_dev, ppp_init, };
  596. static struct device ppp1_dev = {
  597.     "ppp1", 0x0, 0x0, 0x0, 0x0, 1, 0, 0, 0, 0, &ppp2_dev, ppp_init, };
  598. static struct device ppp0_dev = {
  599.     "ppp0", 0x0, 0x0, 0x0, 0x0, 0, 0, 0, 0, 0, &ppp1_dev, ppp_init, };
  600. #undef NEXT_DEV
  601. #define NEXT_DEV (&ppp0_dev)
  602. #endif   /* PPP */
  603.  
  604. The pattern should be obvious.  For more channels, you need to add
  605. more "static struct device pppN_dev" lines, changing the first, sixth
  606. and eleventh structure entries as appropriate.  The highest numbered
  607. PPP device should have NEXT_DEV in its eleventh structure field, and
  608. you should change the ppp3_dev structure to have &ppp4_dev there
  609. instead.
  610.  
  611. For example, to add 2 extra channels, you would have
  612.  
  613. #if defined(CONFIG_PPP)
  614. extern int ppp_init(struct device *);
  615. static struct device ppp5_dev = {
  616.     "ppp5", 0x0, 0x0, 0x0, 0x0, 5, 0, 0, 0, 0, NEXT_DEV,  ppp_init, };
  617. static struct device ppp4_dev = {
  618.     "ppp4", 0x0, 0x0, 0x0, 0x0, 4, 0, 0, 0, 0, &ppp5_dev,  ppp_init, };
  619. static struct device ppp3_dev = {
  620.     "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, &ppp4_dev,  ppp_init, };
  621. ... etc.
  622.  
  623. Second, you need to change the line in ppp.h (in include/linux) to
  624. change the line that reads
  625.  
  626. #define PPP_NRUNIT     4
  627.  
  628. to show the new number of channels; in our case it would become
  629.  
  630. #define PPP_NRUNIT     6
  631.  
  632. Finally, recompile and reboot.  The bootup message and the contents of
  633. /proc/net/dev should show the correct number of channels.
  634.  
  635. CHANGES FROM LINUX PPP 0.1.x
  636.  
  637. Linux PPP 0.1.x was based on the free PPP package PPP-1.3.  Linux PPP
  638. 0.2.1 is based on PPP-2.0.4.  There have been some changes to the pppd
  639. options along with significant enhancements.  You should read
  640. "RELNOTES" in the pppd directory for a description of the changes.
  641.  
  642. Also, some options which were added to PPP-1.3 for the Linux version
  643. have now changed names:
  644.     'defroute'  is now 'defaultroute'
  645.     'kerndebug' is now 'kdebug'
  646.     'dropdtr'   is now 'modem'
  647. In addition, it is now necessary to use the 'noipdefault' option if
  648. you want to get the local IP address from the remote PPP server.
  649.  
  650. CONCLUSION
  651.  
  652. Good luck!
  653.  
  654. Michael
  655.